Core Question

如何把 identity、delegation、authorization、approval、revocation 與 evidence 整合成可落地、可演進的企業架構？

今天的問題

企業想讓「採購 Agent」替員工查詢供應商、建立訂單、要求主管批准高風險付款。若只發一個萬能 Agent token，所有問題都被壓在同一個 subject：誰在跑、代表誰、可以做什麼、撤銷是否生效、如何證明，全部無法分辨。本系列的答案是一組可組合的 authority controls，而不是單一 token。

為什麼這不是傳統 IAM 問題

Agent 會把 intent 動態拆成多個 Action、跨 Tool 組合、代表 User、委派給其他 Agent，並在長任務中遇到 approval、revocation 與 partial outcome。企業 reference architecture 必須同時處理 control plane、runtime plane 與 evidence plane；拿掉 Agent 後，這個多步 autonomous authority lifecycle 不再成立。

Threat / Failure Scenario

若企業只發一個萬能 Agent token，任一 Tool 都可能把 User、Agent、Task 與 approval 壓成同一 subject；撤銷、最小權限、歸責與事後證明都會失去可操作的 enforcement point。

核心概念

核心收斂

三個問題貫穿全系列：Agent 是誰？由可驗證的 workload/instance identity 回答；代表誰？由 User subject 與 bounded Delegation Context 回答；憑什麼執行？由逐 Action PDP decision、必要的 Human Approval、PEP enforcement 和 Resource-side check 回答。Task、資料標籤、Tool composition、期限、risk 和 revocation epoch 都是 decision input。

Architecture Pattern

Naive / Unsafe Design

User -> Agent (萬能 token) -> every Tool -> Resource
log: HTTP status only

Recommended Enterprise Reference Architecture

Control plane 管理註冊、identity、delegation、policy、approval 與 revocation；runtime plane 執行 Agent plan、Gateway、Tool 和 Resource；evidence plane 關聯 request → decision → execution → outcome。Trust boundaries 不因同一 cluster 而消失：User/Agent、Agent/Gateway、Gateway/PDP、Gateway/Tool、Tool/Resource 各自驗證。Identity flow 是 subject + actor + task grant → PDP；Authorization Decision Point 是 PDP，PEP 是 Gateway，Resource 保留最後防線。

分階段落地

1. 可識別： 為每個 Agent workload/instance 配短效、audience-bound identity；分離 User subject 與 actor。
2. 可限制： 把自然語言 intent 正規化為 task grant，逐 Action 評估 resource、parameters、risk、data flow 和 tool sequence。
3. 可中止： 高風險要求 action-bound approval；長任務用 checkpoint、lease、epoch、idempotency 與 compensation。
4. 可證明： 用 trace correlation 串 lifecycle；以 signed decision receipt 綁 canonical Action；獨立保存 Resource outcome。
5. 可治理： 管理 Agent owner、版本、assurance、policy version、retention、key rotation、撤銷和跨 trust-domain federation。

Cloud 或產品 mapping 應在這個通用模型之後進行：任何能提供 workload identity、policy decision、gateway enforcement、簽章金鑰和 immutable/evidentiary storage 的組合都可實作；不能以某個平台的 service account 取代上述責任分界。

小型 PoC

state = {"grant": True, "approval": False, "revoked": False, "evidence": []}
def decide(action):
    if state["revoked"]: return "deny:revoked"
    if action == "pay" and not state["approval"]: return "approval_required"
    return "allow"
def run(action):
    d = decide(action); state["evidence"].append((action, d))
    if d == "allow": state["evidence"].append((action, "outcome:success"))
    return d

assert run("read") == "allow"
assert run("pay") == "approval_required"
state["approval"] = True
assert run("pay") == "allow"
state["revoked"] = True
assert run("notify") == "deny:revoked"
assert [x[1] for x in state["evidence"]] == ["allow", "outcome:success", "approval_required", "allow", "outcome:success", "deny:revoked"]
print("allow, approval, allow-after-approval, deny-after-revocation")

PoC 覆蓋 allow、deny、approval、revocation 與 audit reconstruction 的最小狀態路徑；它沒有實作真實簽章、分散式一致性或 provider compensation，這些是部署前必須另外做的整合驗證。

今天得到什麼

• 企業需要分離 User Identity、Agent Identity、Delegation Context 與 Action authorization。
• PDP 決策、PEP enforcement、Human Approval、Revocation 與 Resource outcome 是不同責任。
• Task-bound、time-bound、data-bound、sequence-bound 和 audience-bound controls 共同實現 least agency。
• Audit log 提供可調查性；signed receipt 與 outcome evidence 才能進一步建立可驗證鏈。
• 採用應從可識別、可限制、可中止、可證明、可治理五個能力階段演進。

下一篇

這是 30 天系列的終點，也是企業落地工作的起點。接下來應以這套 reference architecture 逐步驗證自身的 Agent use case、trust assumptions 與 enforcement gaps，而不是尋找一個能取代整套架構的萬能 Token。

參考資料

• NIST SP 800-207 Zero Trust Architecture
• RFC 8693: OAuth 2.0 Token Exchange
• RFC 7515: JSON Web Signature
• OpenTelemetry Context specification
• SPIFFE Overview